PC Direct 1995 May

home *** CD-ROM | disk | FTP | other *** search

/ PC Direct 1995 May / PC Direct CD-ROM (May 1995).ISO / ipe / misc / dosup9.exe / ODIINFO.DOC < prev next >

Wrap

Text File | 1992-12-09 | 23.9 KB | 539 lines

The Open Data-Link Interface (ODI) Overview A discussion on why Novell is promoting the transition to the ODI specification: A comparision between Novell's Dedicated IPX and ODI, an ODI architectural overview, and a comparison between ODI and Microsoft's NDIS. Prepared By Novell Labs Marketing Revision 1.4 Introduction This paper provides an overview of ODI from several vantage points. The first section will compare ODI with Dedicated IPX. The second section contains an architectural overview of ODI and explains the different components and how they interact. The third section is a comparison of ODI with Microsoft's NDIS. The focus of this paper will be in helping to understand the advantages of ODI and explain why ODI is Novell's recommended specification. Dedicated IPX drivers have been used for most NetWare installations since NetWare version 2.0A, and still has the largest installed base of any type of LAN driver. As with any technology, it was created to serve a distinct purpose -- act as a bridge between adapter boards and the network communication protocol, connecting hardware with the network operating system. However, many companies have now moved to larger and more complex systems where dedicated IPX drivers have limitations. This growing need for added flexibility in network communication spawned the development of Open Data-Link Interface (ODI). ODI is a data-link specification jointly developed by Apple Computer and Novell and published to the networking industry in 1989. The strategic goal of ODI is to provide seamless network integration at the transport, network, and data-link levels. ODI simplifies the development of network drivers for a wide variety of network adapters and network transport protocol stacks. The result is easier access to a wide variety of networked resources without requiring multiple network connections or additional investments in hardware and software. Section I: Comparing Dedicated IPX and ODI IPX: The way things were To fully understand the improved functionality offered by ODI drivers, you must first understand how dedicated IPX works and what it's limitations are. Dedicated IPX on a DOS workstation allows network clients to communicate with NetWare servers via a single protocol. In a typical DOS IPX installation, a client uses a LAN adapter and a dedicated IPX driver to connect to the network, employing the IPX protocol to communicate with the NetWare server. On the server side, another LAN adapter receives the data, configured for the IPX protocol, and processes the incoming information. Communication goes back and forth between these two entities along this single channel using only the IPX protocol. This works well if all the server has to handle are DOS and OS/2 clients using only the IPX protocol. But networks are getting more and more complex, network managers now need to tie in more and more disparate client types and protocol stacks on one server. What if you need to network DOS, AppleTalk and UNIX? This could not be done under the old Dedicated IPX architecture. ODI: How it addresses the need for flexible protocol support ODI's architecture is designed to radically simplify support for multiple protocols on a single network. Rather than installing a separate driver and adapter for each client type that needs to be supported on the network, ODI consolidates the support for multiple protocols under one driver. This means that one adapter in the server can support various clients on the network. ODI provides transport support so a Apple Macintosh (using the AFP protocol) can use a NetWare server to queue and print documents and save data files that are shareable with other types of workstations. UNIX, OS/2, TCP/IP and other clients can be supported in a similar manner. ODI allows a network to support many different protocols (such as IPX/SPX, TCP/IP and AppleTalk) with ease. ODI also allows network managers to integrate new protocols (or enhancements to existing protocols) into existing networks as they become available. ODI consolidates services on the client side as well. Using the right ODI adapter/driver combination, a workstation can access services from a NetWare server and a UNIX host without rebooting the client. And only one client card is needed to support both IPX and TCP/IP. Thus, ODI allows for multiple types of workstations to communicate transparently with network services through a single server. Furthermore, ODI lets a single protocol stack communicate with multiple LAN cards, (for example, an IPX router) which was not previously possible with Dedicated IPX. ODI drivers are also much easier to install and upgrade than Dedicated IPX drivers: under Dedicated IPX the driver had to be bound to the operating system through NETGEN or SHGEN. If a customer wanted to upgrade the driver, he or she had to re-install (re-gen) the operating system. This can be a time consuming process, especially when considering that the operating system must be re-installed exactly as it was set up before -- whoever does the installation has to know all of the defaults and settings that were set on the original file system, otherwise the system won't be completly functional when it is re-intalled. ODI alleviates this problem entirely by allowing new and updated drivers to be loaded on the fly. Simply unload the existing driver and load the new one, and the underlying file system remains uneffected. ODI has many advantages over Dedicated IPX. Because of these advantages, OS/2 has always been ODI and DOS ODI was shipped with v3.10 and v2.2 Netware and later. A comparison of some of the features and capabilities between the two are listed below. A Comparison of Dedicated IPX and ODI Frame type support DEDICATED IPX: Ethernet Frame types Supported: 802.3 Ethernet II Token Ring ODI: Ethernet Frame types Supported: 802.2 802.3 Ethernet II Snap Token Ring: 802.5 802.2 Snap BENEFITS OF ODI: One driver allows the customer to easily support multiple frame types on the same network. This opens the network up to more products and platforms. Protocol support DEDICATED IPX: Supports a single protocol stack: IPX Appletalk (on the server) ODI: Supports multiple protocol stacks simultaneously: IPX TCP/IP AppleTalk OSI ...etc... BENEFITS OF ODI: Allows for multiple protocol support under a single card and driver. This provides easier maintenance for hooking up multiple clients to a single server and accessing resources from host servers. Physical board support DEDICATED IPX: Supports up to 4 physical boards in server ODI: Supports up to 255 logical boards in server or as many physical boards as will fit in the machine BENEFITS OF ODI: Provides support for a larger number of LAN boards. Allows for balancing of network load over multiple cards. Throughput capacity DEDICATED IPX: Max packet size = Up to 4k only in powers of 2 (512, 1k, 2k, 4k) ODI: Max packet size = Up to 24k depending on media and board limitations BENEFITS OF ODI: Substantially increases total network throughput. Ease of maintenance DEDICATED IPX: Drivers may not be unloaded ODI: Drivers can be loaded on the fly. BENEFITS OF ODI: Allows you to upgrade LAN drivers with minimal interruption to network services. No need to re-install operating system. Additional Features ODI: Also supports: Lanalyzer for NetWare Packet Burst Locally administered node addresses BENEFITS OF ODI: ODI supports network services that Dedicated IPX currently does not support. Additional network services will be compatible with ODI as they are provided. Section II: Architectural Overview With ODI, any LAN driver can communicate with any ODI protocol stack. The diagram below shows the modular structure of ODI. The three components of ODI technology are: Multi-Link Interface Driver (MLID) Link Support Layer (LSL) Protocol Stacks Multi-Link Interface Driver (MLID) The Multi-Link Interface Driver (MLID) is a network interface card driver developed to the ODI MLI specifications. The MLID controls communication between the LAN board and the Link Support Layer. There are two parts to the MLID: the Media Support Module (MSM) and the Hardware-Specific Module (HSM). The MSM is source code provided by Novell that implements the standard functions of LAN drivers into ODI for each of the standard media types. The HSM is the code written by the developer to handle the LAN board details. When the MLID receives a packet of data, it removes the media access information (MAC header) and passes the packet to the Link Support Layer. Since the media details are invisible to the LSL, this modular design provides true media independence. Link Support Layer (LSL) The Link Support Layer (LSL) is the technological factor that allows a single driver to support multiple protocols and for a protocol to use multiple drivers. When the LSL receives a packet of data from the MLID, the LSL acts as a switchboard by determining which protocol stack should receive the packet. This "traffic cop" functionality eliminates the need to write separate drivers for each frame/protocol combination, thereby dramatically reducing the number of drivers a developer has to write and a customer has to install. Protocol stacks The protocol stack receives packets of information from the LSL and is unaware of the media or LAN board type through which it passed. It then removes the protocol specific header information and passes the packets on to other higher-layer protocols or applications. The most popular types of protocol stacks are IPX/SPX, TCP/IP, AppleTalk, and OSI. The modular design of ODI is the key to its flexibility. This modularity is created by making sure that the protocol stacks are unaware of media knowledge and that the MLIDs are unaware of protocol knowledge. The drivers and the protocol stacks operate independent of each other making it possible to add new media or new protocols to the file system easily. Section III: Comparing NDIS and ODI NDIS was co-developed by 3COM and Microsoft. A drawing is included below to compare the conceptual architectural models of NDIS and ODI. This will provide a basis for understanding the differences between the two specifications. (Note: this discussion is not meant to be an engineering- level comparison of the two specifications, but rather provide a basic working knowledge of the important differences between NDIS and ODI.) There are several distinct differences between ODI and NDIS that end up affecting the value of products written to the different specifications. While both specifications promote schemes to support multiple protocols on an internetwork, their different approaches to enabling this functionality result in dramatically different customer implementations. Novell's orientation on driver support is that it should be as invisible as possible to the customer. There are many issues to consider when trying to make driver support invisible to customers: * Technical competence: Does the driver actually do what it is supposed to do: support multiple protocols? Does it do so efficiently and gracefully? * Flexibility: Can additional protocols be supported as they are developed? What about additional media, such as FDDI or ATM? How difficult is it to integrate support for these new products as they emerge? Will products based on new media or protocols work with products developed to the existing architectural specs? * Backward compatibility: If you are a customer and have invested in products that support ODI, will future versions of ODI continue to support these products or will you have to replace drivers? What about NDIS? * Reliability: How can a customer determine if a third party product really conforms to a spec, whether it be ODI or NDIS? What difference does this make to a customer? How well will different products from different vendors, written to the same spec, interoperate? * Development issues: How long does it take to develop ODI drivers? What is being done to reduce development time even further? How does this affect driver availability to the customer? What advantages does a "modular" approach offer over a "media-dependent" approach? How does the ODINSUP shim (available through ODI) make NDIS driver development practically unnecessary? Flexibility NDIS protocol stacks are media aware --they contain media knowledge in the protocol stack. Almost all NDIS stacks will recognize and support Ethernet 802.3 or TokenRing 802.5 or both. This means that drivers for other media such as Arcnet or ATM must shim this media to make it look like 802.3 or 802.5. As a result NDIS drivers have been much more difficult to write to any media other than Ethernet and TokenRing. This is not so with ODI. ODI was designed to transparently support any network transport regardless of the underlying media. For instance, ODI will integrate FDDI, wireless technology or other media types into your present network without the need to rewrite or change the protocol stacks. The method NDIS employs to support multiple protocol stacks can also be an issue, especially in cases where true multiprotocol support is needed. When a system uses multiple protocol stacks, NDIS is set up to daisy chain the packets from stack to stack (through the Protocol Manager) until the packet is recognized and received. This works well as long as the data packet always needs to go to the first protocol stack in the chain, but if the traffic is evenly spread across several stacks, or a new stack is added in later, then the Protocol Manager will spend a lot of time toggling between stacks looking for the right route for data transmission and the protocol stacks at the front of the chain will get higher performance than those at the back. Microsoft suggests that the protocols should be loaded in order of network traffic use so as to speed up the throughput. But when a new protocol is added to the network, it is the last protocol to get passed the packet of information. If this new protocol is going to be used for most of the network transportation, then to get optimal speed under NDIS, you would be required to reload all of the protocol stacks, making sure that the new stack was loaded first. In any case, the customer must have knowledge of NDIS and tweak the NDIS system to get good performance from the system. Again, the philosophy behind ODI is to minimize customer involvement with the system -- set the system up so that the system takes care of all of the transport details. Under ODI, the LSL determines which protocol stack should receive each packet of information and the loading order is irrelevant. A stack can be added into the system and ODI automatically supports it. And loading and unloading drivers with ODI is much easier than with NDIS: NDIS driver loading is done in the config.sys file, while ODI is a TSR and, under DOS, provides more flexibility for loading and unloading drivers. Reliability Another important comparison to make between ODI and NDIS is how to gauge the reliability of drivers written to each specification. Currently Microsoft provides test tools to developers so that they can test their own drivers after they write them. No outside testing or verification is required for the drivers, so a customer really has no way of knowing how well tested or reliable an NDIS driver is. This is more risky when compared to the standards Novell has set for ODI. Novell has established a department specifically designed to test and certify drivers written by developers. This is done to assure that the drivers meet specifications and run in various configurations. In a sense, Novell Labs has established a watermark that developers must meet in order to call a product an ODI driver. Furthermore, once an ODI driver is certified, Novell Services treats it as if it were one of Novell's drivers. If a customer running NetWare encounters a driver-related problem, Novell assumes a role in getting the problem solved. If, however, the driver is NDIS, then Services has no documentation to refer to solve the problem and cannot do much to help the customer. Considered from a customer's standpoint, this is an important distinction. If customers base their systems on ODI drivers, they know that the products they are using have already demonstrated a significant level of compatibility with NetWare and can be supported if something should go wrong. If they go with NDIS, they are taking their own chances. In large part because of these reliability issues, we have heard of many large accounts that have standardized on ODI drivers. ODI drivers are certified by Novell Labs; other drivers do not have to meet this requirement. Backward compatibility Another important distinction between the two specifications has to do with backward compatibility. For example, consider a customer running with NDIS v2.0 drivers that wants to upgrade to Windows NT. NT requires v3.0 drivers. This presents a problem if the board vendor hasn't released a v3.0 driver for the customer's board when he/she wants to install NT. Ironically, because ODI supports any protocol stack, an ODI driver for the same board can be used to connect into NT through a shim called ODINSUP. This module allows the customer to talk to the NDIS protocol stacks unmodified over the ODI driver. ODINSUP is discussed in more detail in the following section. Because of Novell's customer focus ODI provides complete backwards compatibility, making upgrading much simpler. Again, once an ODI driver is installed, changes to the system, whether they be new protocol stacks, new media, or products that support a new ODI spec have no impact on the driver's compatibility. This dramatically reduces the customer' s support and maintenance burden. Development Issues Time to market LAN drivers used to take six to eight to develop before ODI was introduced. Because of ODI's modular architecture, development time to market has been significantly reduced. As we have previously outlined, ODI drivers are comprised of two parts: the Media Support Module (MSM) and the Hardware-Specific Module (HSM). In the past when developers wrote drivers they had to create code to access the protocol, service the board, and access the media. In order to simplify driver development, Novell now provides source code to interface with various media (the MSM) as part of the Novell LAN Driver Development Kit. This reduces the developer's coding burden: now they can focus on creating the hardware-specific portions of the driver and adding any optional functions. ODI's MSM/HSM drivers can be developed in 2-3 weeks. Chipset developers have also helped to make driver development much simpler than it was in the past. Major silicon developers (including National, Intel Texas Instruments and AMD) have sample designs, software source code, bills of materials and other materials needed to build products that support ODI. These materials are available to developers that use their chipsets. This simplification of the development process benefits customers in two ways: * Drivers become more standardized, easier to create, and easier to test. Ultimately, this means that they will become less expensive to produce, resulting in lower-priced products that are available sooner to customers. * As more of the coding related to the network interfaces becomes standardized, developers can focus their attention on building greater functionality and performance into their products. Greater speed to market means that bug fixes and patches that increase performance (such as the packet burst NLM) will be integrated more quickly and with less downtime than was previously possible. ODINSUP As part of Novell's commitment to be interoperable, ODI supports NDIS. ODI's modular architecture allows users to support NDIS protocol stacks. A module called ODINSUP allows NDIS protocol stacks to run unmodified over the ODI LSL and talk to an ODI LAN driver (please refer to the figure on the following page). Now, multi-vendor network transports like IBM's NetBEUI, DEC's LAT or 3COM's XNS can be run over a common Data-Link (driver) specification. This feature provides two significant benefits: * It allows customers to integrate, and preserve investments in, multi-vendor networking services. Because ODI supports NDIS stacks, customers can standardize on ODI drivers, knowing that these drivers will support all of their networking needs, whether they depend on NDIS or another network transport protocol. * The ability to access NDIS through ODINSUP also means that developers can develop products to the ODI specification knowing that these drivers will be able to support NDIS protocol stacks. This feature significantly reduces a LAN driver developer's coding burden. Modular architecture of ODI allows integration of new technologies without disrupting current services, including support for NDIS stacks and FDDI. Summary ODI was developed with a modular architecture that makes it truly media and protocol independent. ODI provides greater flexibility in configuring the network interface, uses resources more effectively and preserves investments in hardware and other network resources. With ODI, integration of new technologies can be done easily and without interrupting current services. ODI drivers are certified by Novell Labs and are therefore very reliable, and are compatible with previous versions of the ODI spec. Driver development time has been reduced due to the source code provided by Novell; this means better products get to customers more quickly. ODI drivers can talk to NDIS stacks through ODINSUP, allowing customers to standardize on one type of drivers. Because of these advantages, Novell recommends products written to ODI. How to Switch to ODI Because of these advantages, Novell is including only ODI drivers with the NetWare v4.0 operating system. Older dedicated IPX drivers are being phased out -- Novell Labs discontinued the certification of dedicated DOS IPX drivers June 1992. There are now ODI drivers available for all popular LAN adapters. See the attached appendix for a listing of tested drivers. In order to assist in upgrading DOS workstations from dedicated IPX drivers to ODI, Novell is supplying a utility, (available in upcoming client workstation kits) called WSUPGRD, which is intended to be used by a system administrator to upgrade many workstations which are all similarly configured. This utility is intended to be executed from the system login script. It will scan the dedicated IPX.COM file on the workstation, determine which driver was linked in with the SHGEN utility and what hardware options were selected. It will then reference an installation file created by the system administrator to select the appropriate ODI driver, and will install it along with the ODI Link Support Layer (LSL) module and an appropriate NET.CFG file (all of which may be configured or defined by the system administrator). This utility is intended for use in upgrading large sites where workstations with similar brands of LAN adapters are also similar in configuration (usually under the control of a system administrator). For example, when the command lines in the autoexec.bat files are similar, this utility will easily upgrade all the similar adapters.